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Abstract 

Many software as well digital hardware automatic synthesis meth- 
ods define the set of implementations meeting the given system speci- 
fications with a boolean relation K. In such a context a fundamental 
step in the software (hardware) synthesis process is finding effective 
solutions to the functional equation defined by K. This entails finding 
a (set of) boolean function(s) F (typically represented using OBDDs, 
Ordered Binary Decision Diagrams) such that: 1) for all x for which 
K is satisfiable, K{x,F{x)) = 1 holds; 2) the implementation of F is 
efficient with respect to given implementation parameters such as code 
size or execution time. While this problem has been widely studied in 
digital hardware synthesis, little has been done in a software synthesis 
context. Unfortunately the approaches developed for hardware syn- 
thesis cannot be directly used in a software context. This motivates 
investigation of effective methods to solve the above problem when F 
has to be implemented with software. 

In this paper we present an algorithm that, from an OBDD repre- 
sentation for K, generates a C code implementation for F that has the 
same size as the OBDD for F and a WCET ( Worst Case Execution 
Time) at most 0{nr), being n = \x\ the number of input arguments 
for functions in F and r the number of functions in F. 
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1 Introduction 



Many software as well digital hardware automatic synthesis methods define 
the set of implementations meeting the given system specifications with a 
boolean relation K. Such relation typically takes as input (the n-bits encod- 
ing of) a state x of the system and (the r-bits encoding of) a proposed action 
to be performed u, and returns true (i.e. 1) iff the system specifications are 
met when performing action u in state x. In such a context a fundamental 
step in the software (hardware) synthesis process is finding effective solutions 
to the functional equation defined by i.e. K{x,u) = 1. This entails find- 
ing a tuple of boolean functions F = (/i, . . . , /r) (typically represented using 
OBDDs, Ordered Binary Decision Diagrams |1]) s.t. 1) for all x for which K 
is satisfiable (i.e., it enables at least one action), K{x,F{x)) = 1 holds, and 
2) the implementation of F is efficient with respect to given implementation 
parameters such as code size or execution time. 

While this problem has been widely studied in digital hardware synthe- 
sis [2], little has been done in a software synthesis context. This is not surpris- 
ing since software synthesis from formal specifications is still in its infancy. 
Unfortunately the approaches developed for hardware synthesis cannot be 
directly used in a software context. In fact, synthesis methods targeting a 
hardware implementation typically aim at minimizing the number of digi- 
tal gates and of hierarchy levels. Since in the same hierarchy level gates 
output computation is parallel, the hardware implementation WCET ( Worst 
Case Execution Time) is given by the number of levels. On the other hand, a 
software implementation will have to sequentially compute the gates outputs. 
This implies that the software implementation WCET is the number of gates 
used, while a synthesis method targeting a software implementation may ob- 
tain a better WCET. This motivates investigation of effective methods to 
solve the above problem when F has to be implemented with software. 

1.1 Our Contribution 

In this paper we present an algorithm that, from an OBDD representation 
for K, effectively generates a C code implementation for K. This is done in 
two steps: 

1. from an OBDD representation for K we effectively compute an OBDD 
representation for F, following the lines of |1U] : 
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2. we generate a C code implementation for F that has the same size as 
the OBDD for F and a 0{nr) WCET, being n = \x\ the size of states 
encoding and r = |u| the size of actions encoding. Indeed, we prove a 
more strict upper bound for the WCET by also considering the heights 
of the OBDDs representing F. 

We formally prove both steps [T] and |2] to be correct. This allows us 
to synthesize correct-by-construction control software, provided that K is 
provably correct w.r.t. initial formal specifications. This is the case of [7], 
where an algorithm to synthesize K starting from the formal specification of a 
Discrete-Time Linear Hybrid System {DTLHS m the following) is presented. 
Thus this methodology allows a correct-by-construction control software to 
be synthesized, starting from formal specifications for DTLHSs. 

Note that the problem of solving the functional equation K{x, F{x)) = 1 
w.r.t. F is trivially decidable, since there are finitely many F. However, 
trying to explicitly enumerate all F requires time f2(2''^") (being n the number 
of bits encoding state x and r the number of bits encoding state u). By using 
OBDD-based computations, our algorithm complexity is 0{r2^) in the worst 
case. However, in many interesting cases OBDD sizes and computations 
are much lower than the theoretical worst case (e.g. in Model Checking 
applications, see [6]). 

Furthermore, once the OBDD representation for F has been computed, 
a trivial implementation of F could use a look-up table in RAM. While 
this solution would yield a better WCET, it would imply a Q{r2'^) RAM 
usage. Unfortunately, implementations for F in real-world cases are typically 
implemented on microcontrollers (this is the case e.g. for embedded systems). 
Since microcontrollers usually have a small RAM, the look-up table based 
solution is not feasible in many interesting cases. The approach we present 
here only requires 0{n + r) bytes of RAM for the data. As for the program 
size, it is linear in the size (i.e., number of nodes) of the OBDDs representing 
F, thus again we rely on the compression OBDDs achieve in many interesting 
cases. 

Moreover, F : B" — >■ is composed by r boolean functions, thus it is 
represented by r OBDDs. Such OBDDs typically share nodes among them. If 
a trivial implementation of F in C code is used, i.e. each OBDD is translated 
as a stand-alone C function, OBDDs nodes sharing will not be exploited. In 
our approach, we also exploit nodes sharing, thus the control software we 
generate fully takes advantage of OBDDs compression. 
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Finally, we present experimental results showing effectiveness of the pro- 
posed algorithm. As an example, in less than 1 second and within 70 MB of 
RAM we are able to synthesize the control software for a function K of 24 
boolean variables, divided in n = 20 state variables and r = 4 action vari- 
ables, represented by a OBDD with about 4 x 10^ nodes. Such K represents 
the set of correct implementations for a real-world system, namely a multi- 
input buck DC/DC converter [S], obtained as described in [7]. The control 
software we synthesize in such a case has about 1.2 x 10^ lines of code, whilest 
a control software not taking into account OBDDs nodes sharing would have 
had about 1.5 x 10^ lines of code. Thus, we obtain a 24% gain towards a 
trivial implementation. 

1.2 Related Work 

Synthesis of boolean functions F satisfying a given boolean relation K in 
a way s.t. K{x,F{x)) = 1 is also addressed in [2]. However, [2] targets a 
hardware setting, whereas we are interested in a software implementation 
for F . Due to structural differences between hardware and software based 
implementations (see the discussion above), the method in [2] is not directly 
applicable here. 

In [7] an algorithm is presented which, starting from formal specifications 
of a DTLHS, synthesizes a correct-by-construction boolean relation K, and 
then a correct-by-construction control software implementation for K. How- 
ever, in [7] the implementation of K is neither described in detail, nor it is 
proved to be correct. Furthermore, the implementation synthesis described 
in [7] has not the same size of the OBDD for F, i.e. it does not exploit 
OBDD node sharing. 

In [TU] an algorithm is presented which computes boolean functions F 
satisfying a given boolean relation in a way s.t. K{x,F{x)) = 1. This 
approach is very similar to ours. However [10] does not generate the C code 
control software and it does not exploit OBDD node sharing. Furthermore, 
the algorithm is not proved to be correct. 

Therefore, to the best of our knowledge this is the first time that an 
algorithm synthesizing correct-by-construction control software starting from 
a boolean relation (with the characteristics given in Sect. II. ip is presented 
and proved to be correct. 
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2 Basic Definitions 



In the following, we denote with B = {0, 1} the boolean domain, where 
stands for false and 1 for true. We will denote boolean functions / : B" — >■ B 
with boolean expressions on boolean variables involving + (logical OR), • 
(logical AND, usually omitted thus xy = x ■ y) , ^ (logical complementation) 
and © (logical XOR). We also denote with f\xi=g{xi, . . . ,Xn) the boolean 
function f{xi, . . ., Xi-i,g{xi, . . . , Xn),Xi+i, . . . ,Xn) and with 3xi f{xi, . . .,Xn) 
the boolean function f\xi=o{xi, . . . , Xn) + f\xi=i{xi, . . . , x„). We will also de- 
note vectors of boolean variables in boldface, e.g. x = (xi, . . . , Xn). 
Finally, we denote with [n] the set {1, . . . , n}. 

2.1 Feedback Control Problem for Labeled Transition 
Systems 

In this paper we focus on solving and implementing a functional equation 
K[x,u) = 1. In this section we show a typical case in which such an equation 
needs to be solved and implemented. 

A Labeled Transition System (LTS) is a tuple S = {S, A, T) where 5 is a 
finite set of states, A is a finite set of actions, and T: S'xAxS'H-Bis the 
transition relation of S. An LTS is deterministic if T(s, a, s') A T(s, a, s") =^ 
s' = s", and nondeterministic otherwise. A run or path for an LTS S is 
a sequence vr = sq, oq, Si, ai, S2, 02, . . . of states St and actions aj such that 
Vt > OT{st,at, St+i). The length |7r| of a finite run tt is the number of actions 
in vr. We denote with 7r*^'^''(t) the t-th state element of vr. 

A controller for an LTS 5 is a function K : S x A ^ M such that Vs G 5", 
Va e A, if A'(s, a) = 1 then 3s' G 5 T(s, a, s') = 1. We denote with Dom(ir) 
the set of states for which a control action is defined. Formally, Dom(i^) = 
{s G S* I 3a K{s,a)}. S^^^ denotes the closed loop system, that is the LTS 
(5, A, T(^)), where TW(s, a, s') = T(s, a, s') A K{s, a). 

In the following, by assuming proper boolean encoding functions for states 
and actions (as it is usually done in Model Checking applications, see [6]), 
we may see a controller as a boolean function : B" x B'' -> B, with 
n = \\0g2 \S\] and r = \\0g2 \A\]. 

We call a path tt fullpath [T] if either it is infinite or its last state 7r*^'^''(|7r|) 
has no successors (i.e. Adm(5,7r('^)(|7r|)) = 0). We denote with Path(s) 
the set of fuUpaths starting in state s, i.e. the set of fuUpaths tt such that 
7r(^)(0) = s. 
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Given a path vr in S, we define the measure J{S, G, it) on paths as the 
distance of 7r'^'^^(0) to the goal on vr. That is, if there exists n > s.t. 
7r^^\n) e G, then J{S,7r,G) = min{ra | > A 7r^^\n) e G}. Otherwise, 
J{S, n, G) = +00. We require n > since our systems are nonterminating 
and each controllable state (including a goal state) must have a path of 
positive length to a goal state. The worst case distance (pessimistic view) of 
a state s from the goal region G is JstmngiS, G, s) = sup{ J(5, G, s, vr) | vr G 
Path(s)}. 

Definition 2.1. Let V = {S, I, G) be a control problem and K he a. con- 
troller for S such that / C Dom(A'). 

K is a strong solution to V if for all s E Dom{K), Jstrongi<S^^\ G , s) is 
finite. 

An optimal strong solution to "P is a strong solution K* to V such that 
for all strong solutions K to V, for all s G S* we have: Jstrong^^^^'^ G, s) < 

•-^strong('5^ \G,s'^. 

Intuitively, a strong solution takes a pessimistic view and requires that for 
each initial state, all runs in the closed loop system reach the goal (no matter 
nondeterminism outcomes). Unless otherwise stated, we call just solution a 
strong solution. 

Definition 2.2. The most general optimal (mgo) strong solution (simply 
mgo in the following) to V is an optimal strong solution ^ to P such that 
for all other optimal strong solutions K to P, for all s G 5, for all a G A we 
have that K[s,a) ^ K{s,a). 

Efficient algorithms to compute mgos starting from suitable (nondeter- 
ministic) LTSs have been proposed in the literature (e.g. see [5]). Once an 
mgo K has been computed, solving and implementing the functional equa- 
tion K{x, u) = 1 allows a correct-by-construction control software to be 
synthesized. 

2.2 OBDD Representation for Boolean Functions 

A Binary Decision Diagram (BDD) i? is a rooted directed acyclic graph 
(DAG) with the following properties. Each R node v is labeled either with a 
boolean variable var(u) (internal node) or with a boolean constant val(f ) G B 
(terminal node). Each R internal node v has exactly two children, labeled 
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with high(f) and low(f). Let Xi,. . . be the boolean variables labeling 
R internal nodes. Each terminal node v represents the (constant) boolean 
function fv{xi, . . . , Xn) = val(w). Each internal node v represents the boolean 
function fy{xi, ...,Xn) = Xifhighiv){xi, . . . , x„) + Xi/iow{«)(a:i, • • • , Xn), being 
Xi = var(i;). 

An Ordered BDD (OBDD) is a BDD where, on each path from the root 
to a terminal node, the variables labeling each internal node must follow the 
same ordering. Two OBDDs are isomorphic iff there exists a mapping from 
nodes to nodes preserving attributes var, val, high and low. 

An OBDD is called reduced iff it contains no vertex v with low(w) = 
high(t'), nor does it contain distinct vertices v and v' such that the subgraphs 
rooted by v and v' are isomorphic. This entails that isomorphic subgraphs 
are shared, i.e. only one copy of them is effectively stored (see [1]). 

We will only deal with reduced OBDDs, thus we will call them simply 
OBDDs. It can be shown [1] that each boolean function can be represented 
by exactly one OBDD (up to isomorphism), thus OBDD representation for 
boolean functions is canonical. 

3 Solving a Boolean Functional Equation 

Let K{xi, . . . , Xn, Ui, . . . , Ur) be an mgo for a given control problem V = 
[S, I, G). We want to solve the boolean functional equation K{x,u) = 1 
w.r.t. variables u, that is we want to obtain boolean functions fi, . . . , fr s.t. 

K{X, fi{x), fr{x)) = K\u^=f^(a:),...,Ur=Mx)ix, u) = 1. 

This problem may be solved in different ways, depending on the target 
implementation (hardware or software) for functions /j. In both cases, it is 
crucial to be able to bound the WCET ( Worst Case Execution Time) of the 
obtained controller. In fact, controllers must work in an endless closed loop 
with the system S (plant) they control. This implies that, every T seconds 
[sampling time), the controller has to decide the actions to be sent to the 
plant. Thus, in order for the entire system (plant + control software) to 
properly work, the controller WCET upper bound must be at most T. 

In P], fi, . . . , fr are generated in order to optimize a hardware imple- 
mentation. In this paper, we focus on software implementations for fi (con- 
trol software). As it is discussed in Sect. [H simply translating an hardware 
implementation into a software implementation would result in a too high 
WCET. Thus, a method directly targeting software is needed. An easy so- 
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lution would be to set up, for a given state x, a SAT problem instance 
C = Cki, • • • , Cxt, Ci, . . . , c„, where Cki A ... A Cxt is equisatisfiable to K 
and each clause q is either Xi (if Xi is 1) or Xi (otherwise). Then C may be 
solved using a SAT solver, and the values assigned to u in the computed 
satisfying assignment may be returned as the action to be taken. However, 
it would be hard to estimate a WCET for such an implementation. The 
method we propose in this paper overcomes such obstructions by achieving 
a WCET at most proportional to rn. 

4 OBDDs with Complemented Edges 

In this section we introduce OBDDs with complemented edges (COBDDs, 
Def. 14. ip . which were first presented in [3l |9]. Intuitively, they are OBDDs 
where else edges (i.e. edges of type (f , low{v))) may be complemented. Then 
edges (i.e. edges of type {v, high{v))) complementation is not allowed to 
retain canonicity. Edge complementation usually reduce resources usage, 
both in terms of CPU and memory. 

Definition 4.1. An OBDD with complemented edges (COBDD in the fol- 
lowing) is a tuple p = (V, V, 1, var, low, high, flip) with the following 
properties: 

1. V = {xi, . . . ,Xn} is a finite set of boolean variables s.t. for all Xj ^ 
Xj G V, either Xi < Xj or xj < Xi] 

2. y is a finite set of nodes; 

3. 1 G V is the terminal node of p, corresponding to the boolean constant 
1; any non-terminal node v &V,v ^1 is called internal; 

4. var, low, high, flip are functions defined on internal nodes, namely: 

• var : V\{1} ^ V assigns to each internal node a boolean variable 
in V; 

• high : \ {1} — )■ V assigns to each internal node v a high child 
(or true child), representing the case in which var(t;) = 1; 

• low : V \{1} ^ V assigns to each internal node v a low child (or 
else child), representing the case in which va.T{v) = 0; 
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• flip : {1} — 7- B assigns to each internal node v a boolean value; 
namely, if flip(t;) = 1 then the else child has to be complemented, 
otherwise it is regular (i.e. non-complemented); 

5. for each internal node f, var(t;) < var(high(f)) andvar(f) < var(low(w)). 

COBDDs as (labeled) DAGs A COBDD p = {V,V,l, var, low, high, 
flip) deflnes a labeled directed multigraph in a straightforward way. This is 
detailed in Def. IS 

Definition 4.2. Let p = (V, V, 1, var, low, high, flip) be a COBDD. The 

graph associated to p is a labeled directed multigraph G*-^-* = {V, E) where V 
is the same set of nodes of p and: 

1. E = {{v,w) \ w = high(?;) M w = low(t')} {E is a multiset since it may 
happen that high(i;) = low(t;) for some v eV)\ 

2. the following labeling functions are deflned on nodes and edges: 

• ind : \ {1} — )■ V assigns to each internal node v a boolean 
variable in V, and is deflned by ind(w) = var(w); 

• type : E — {then, else, compl} assigns to each edge e = {v, w) its 
type, and is deflned by: type(e) = then [then edge) iff high(w) = 
w, type(e) = else {regular else edge) iff low(f) = w A flip(f) = 
0, type(e) = compl {complemented else edge) iff low(t;) = w A 
flip(tO = 1. 

Example 4.3. Let p = {{xq, xi, X2}, {0x15, 0x14, 0x13, Oxe, 1}, 1, 
var, low, high, flip) he a COBDD with: i) var (0x15) = Xq, var(0xl4) = 
var(0xl3) = xi, var(Oxe) = X2 and xq < xi < X2; ii) high(0xl5) = 0x13, 
low(0xl5) = 0x14, high(0xl3) = high(0xl4) = Oxe, high(Oxe) = low(Oxe) = 
low(0xl3) = low(0xl4) = 1,- m; flip(0xl4) = 0, flip(0xl5) = flip(0xl3) = 
flip (Oxe) = 1. 

Then G^^^ is shown in Fig. [1[ where edges are directed downwards. More- 
over, in Fig. [H then edges are solid lines, regular else edges are dashed lines 
and complemented else edges are dotted lines. 
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Restriction of a COBDD The graph associated to a given COBDD may 
be seen as a forest with multiple rooted multigraphs. Def. 14.41 allow us to 
select one root vertex and thus one rooted multigraph. 

Definition 4.4. Let p = (V, V, 1, var, low, high, flip) be a COBDD, and 
let V eV. The COBDD restricted to v is the COBDD = (V, K, 1, var„, 
low„, high^, flip^) s.t.: 

• Vy = {w G V I there exists a path from v to w in G*^^^} (note that 

• var^,, low^,, high„ and flip„ are the restrictions to K of var, low, high 
and flip. 

Reduced COBDDs Two COBDDs are isomorphic iff there exists a map- 
ping from nodes to nodes preserving attributes var, flip, high and low. A 
COBDD is called reduced iff it contains no vertex v with low(f ) = high(u) A 
flip(f ) = 0, nor does it contains distinct vertices v and v' such that p„ and 
Pt,/ are isomorphic. Note that, differently from OBDDs, it is possible that 
high(i;) = \ow{v) for some v ^ V, provided that flip(t;) = 1 (e.g. see nodes 
Oxf and Oxe in Fig. [3]). In the following, we assume all our COBDDs to be 
reduced. 

COBDDs Properties For a given COBDD p = (V, V, 1, var, low, high, 
flip) the following properties follow from deflnitions 14.11 and 14.21 i) G^^^ is 
a rooted directed acyclic (multi)graph (DAG); ii) each path in G^^^ starting 
from an internal node ends in 1; iii) let Vi, . . . ,Vk be a path in G^p\ then 
var{vi) < . . . < var{vk). We deflne the height of a node v in a COBDD p 
(notation heightp(w), or simply height (f) if p is understood) as the height of 
the DAG i.e. the length of the longest path from w to 1 in 

4.1 Semantics of a COBDD 

In Def. 14. 51 we deflne the semantics |-] of each node v & V oi a. given COBDD 
p = (V, V, 1, var, low, high, flip) as the boolean function represented by v, 
given the parity b of complemented edges seen on the path from a root to v. 

Definition 4.5. Let p = (V, V, 1, var, low, high, flip) be a COBDD. The 
semantics of a node v eV w.r.t. a flipping hit 6 is a boolean function defined 
as: 
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• := b (base of the induction) 

• {v, bjp := Xj|high(?;), bjp + Xj|low(t>), b © flip(w)]p for any internal node 
V (recursive step), being Xi = var(f). 

When p is understood, we will write |-] instead of |-]p. 

Note that the semantics of a node of a COBDD p is a function of vari- 
ables in V and of an additional boolean variable b. Thus, on each node two 
boolean functions on V are defined (one for each value of b). It can be shown 
(Prop. I4.6p that such boolean functions are complementary. 

Fact 4.6. Let p = {V, V, 1, var, low, high, flip) he a COBDD, let v e V be 
a node and b be a flipping bit. Then Iv, bj = Iv, bj . 

Proof. The proof is by induction on v. As base of the induction, we have 

ii,bj = b = i=pji. 

As induction step, let v be an internal node, and suppose by induction 
that |high(v), bj = |high(t;),6] and l\ow{v), bj = |low(t;),6]. 

Then, since + AC = {A+B){A+C), wehme: lv,bj = Xj|high(t;), fe] + 
Xilhw {v),b @ flip (^)l = {xj + lh.igh{v),bj) {xi + |low(^ ),& ® flip(t ;)l) = 
{Xj + |high(t;),61)( x, + |low(t;),&®fiip(t;)l) = {xi + |hi gh (t;),_&l )(x, + 
|low(t0,6©fiip(v)]) = x,|high(i;),6] +x,|low(t;),6©fiip(v)] = lv,bj. 

□ 

Example 4.7. Let p = {{xq, xi, X2}, {0x15, 0x14, 0x13, Oxe, 1}, 1, var, 
low, high, flip) he the COBDD of Ex. \4-^ If we pick nodes Oxe and 0x14 we 
have |Oxe, bj = X2II, 6] + X2II, 6 © 1] = X26 + X26 = Xa © 6 and |0xl4, bj = 
xi |Oxe, 6] + xi |1, 6 © 0] = xiXqIj + X1X2& + xib = xob + X1X2& + xib. 

Moreover, if we pick node 0x14, then it represents the two following 
boolean functions: |0xl4, 0] = X2 + Xi and |0xl4, 1] = X1X2 (note that 
[0x14,0] = [0x14, 11;. 

Theor.HSlstates that COBDDs are a canomca/ representation for boolean 
functions (see [31 [9]). 

Theorem 4.8. Let / : B" — )■ B 6e a boolean function. Then there exist a 
COBDD p = (V, V, 1, var, low, high, flip), a node v E V and a flipping bit 
6 G B s.t. [f , 6] = f{x). Moreover, let p = (V, V, 1, var, low, high, flip) 
be a COBDD, let Vi,V2 G V be nodes and bi,b2 E M be flipping bits. Then 

{Vi, bij = IV2, 62I iff'Vi = 172 A 61 = 62- 
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Efficient (i.e., at most 0(|V^| log |V^|)) algorithms [3 E] exist to compute 
standard logical operations on COBDDs. We will assume to have available 
the following functions (for instantiation and existential quantifier elimina- 
tion): 

• COBDD_APP s.t. {vapp, hAPp) = COBDD_APP{xi^, Xi^, Vi, h, 
...,Vk, bk, v,b) iff lvApp,bAppj = [f,&l|x,j=H,5ii,...,x,^=K,fefe]; 

• COBDD_EX s.t. {vex, bsx) = COBDD_EX{xi,, x,,, v, b) iflF 
{vex, bEx\ = 3xj,, . . . , Xi^ lv,bj. 

Note that the above defined functions may create new COBDD nodes. 
We assume that such functions also properly update V, var, low, high, ffip 
inside COBDD p (1 and V are not affected). 

5 Automatic Synthesis of C Code from a 
COBDD 

Let K{xi, . . . ,Xn,Ui, . . . , Uj.) be an mgo for a given control problem. Let 
p = (V, V, 1, var, low, high, ffip) be a COBDD s.t. there exist v G 
V, b e M s.t. lv,bj = K{xu...,Xn,Ui,...,Ur). Thus, V = A'UW = 
{xi, . . . , x„}U{mi, . . . , Mr} (we denote with U the disjoint union operator, 
thus X (lU = 0). We will call variables Xj G A" as state variables and 
variables uj G W as action variables. 

We want to solve the boolean functional equation problem introduced 
in Sect. [3] targeting a software implementation. We do this by using a 
COBDD representing all our boolean functions. This allows us to exploit 
COBDD node sharing. This results in an improvement for the method in [TO] , 
which targets a software implementation but which does not exploit sharing. 
Finally, we also synthesize the software (i.e., C code) implementation for 
fi,...,fr, which is not considered in [10]. Given that K is an mgo, this 
results in an optimal control software for the starting LTS. 

5.1 Synthesis Algorithm: Overview 

Our method Synthesize takes as input p, v and b s.t. 6| = K{x,u). 
Then, it returns as output a C function void K(int *x, int *u) with the 
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following property: if, before a call to K, V? x [i — 1] = Xj holds (array indexes 
in C language begin from 0) with x G Dom(J^'), and after the call to K, Vi 
u[z — 1]= holds, then K{x,u) = 1. Moreover, the WCET of function K 
is at most 0{nr). 

Note that our method Synthesize provides an effective implementation of 
the mgo K, i.e. a C function which takes as input the current state of the 
LTS and outputs the action to be taken. Thus, K is indeed a control software. 

Function Synthesize is organized in two phases: 

1. starting from p, v and b (thus from K{x,u)), we generate COBDD 
nodes vi, . . . ,Vr and flipping bits bi, . . . ,br for boolean functions 
fi, . . . , fr s.t. each fi = takes as input the state bit vector 
X and computes the i-th bit Ui of an output action bit vector u, where 
K{x,u) = 1, provided that x G Dom(i^). This computation is carried 
out in function SolveFunctionalEq; 

2. fi,...,fr are translated inside function void K(int *x, int *u). 
This step is performed by maintaining the structure of the COBDD 
nodes representing /i, . . . , /,.. This allows us to exploit COBDD node 
sharing in the generated software. This phase is performed by function 
GenerateCCode. 

Thus function Synthesize is organized as in Alg. [TJ Correctness for func- 
tion Synthesize is proved by Theor. 16.51 

Algorithm 1 Translating COBDDs to a C function 

Require: COBDD p = (V, V, 1, var, low, high, flip), node v G V, boolean 

beM 

Ensure: Synthesize{p,v,b): 
1: {vi, bi, . . . ,Vr, br) <— SolveFunctionalEq{p, v, b) /* first phase */ 
2: GenerateCCode{p, f i, 6i, . . . , Vr, br) /* second phase */ 



5.2 Synthesis Algorithm: Solving Functional Equation 
(First Phase) 

In this phase, starting from p, v and b (thus from = K{x,u)), we 

compute the COBDD nodes vi, . . . and flipping bits bi, . . . ,br having the 
following properties: 
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• for all i G [r], = fi{x) (thus each /j : B" — > B does not depend 
on u); 

• for all X E Dom{K), K{x, fi{x), . . . , fr{x)) = 1. 

In a hardware synthesis setting, techniques to compute /i,...,/^ sat- 
isfying the above functional equation have been widely studied (e.g. 
see [2]). In our software synthesis setting we follow an approach sim- 
ilar to the one presented in [TU] to compute such /i,...,/^. Namely, 
we observe that may be computed using that is fi{x) = 

K{x, fi{x), . . . , fi_i{x),l,Ui+i, . . . ,Un) (see Lemma EH]). This 
allows us to compute COBDD nodes Ui, . . . , and flipping bits b ]^ , . . . , hj^ as 
it is shown in function SoIveFunctionalEq of Alg. [21 Correctness for function 
SolveFunctionalEq is proved in Lemma [6. 2[ 

Algorithm 2 Solving a boolean functional equation 

Require: COBDD p = (V, V, 1, var, low, high, flip), node v E V, boolean 

beM 

Ensure: SolveFunctionalEq{p, v, b): 
1: for all i E [r] do 

2: Ivi, bij ^ COBDD_EX{ui+i, . . . , Un, COBDD_APP{ui, . . . , u„ wi, 6i, 

. . . , Vi_i,bi_i, 1, 0, V, b)) 
3: return {vi,bi, . . . ,Vr,br) 



5.3 Synthesis Algorithm: Generating C Code (Second 
Phase) 

In this phase, starting from COBDD nodes vi, . . . ,Vr and flipping bits bi, . . . ,br 
for functions /i, . . . , generated in the first phase, we generate two C func- 
tions: 

• void K(int *x, int *u), which is the required output function for 
our method Synthesize; 

• int K_bits(int *x, int action), which is an auxiliary function 
called by K. A call to K_bits(x, i) returns fi{x), being x[j — 1]= Xj 
for all j E [n] . 

This phase is detailed in Algs. E] and |H 
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Algorithm 3 Generating C functions 

Require: COBDD p = (V, V, 1, var, low, liigli, flip), nodes vi,...,Vr, 

boolean values bi, . . . ,br 
Ensure: GenerateCCode{p, Vi,bi, . . . ,Vr, br): 
1; print "int K_bits(int *x, int action) { int ret_b; 

switch(action) {" 
2: for all i E [r] do 

3: print "case ": ret_b = ", 6^, "; goto L_", Wj,";" 

4: print "}" /* end of the switch block */ 

5: ^ 

6: for all i E [r] do 

7: W ^ Translate{p, Vi,W); 

8: print "}" /* end of K_bzts */ 

9: print "void K(int *x,int *u){int i; for(i=0;i<", r, ";i++) 
u[i]=K_bits(x,i) ;}" 



Details of Function GenerateCCode (Alg. [3]) Given inputs p, Vi, bi, 
Vr, br (output by SolveFunctionalEq) , Alg. [3] works as follows. First, 
function int K_bits(int *x, int action) is generated. If x[j — 1]= Xj 
for all j E [n], the call K_bits(x, i) has to return fi{x). In order to do 
this, the graph G^^'^i'^ is traversed by taking, in each node the then edge 
if x[j — 1] = 1 (with j s.t. var(t') = Xj) and the else edge otherwise. When 
node 1 is reached, then 1 is returned iff the integer sum c + bi is even, 
being c the number of complemented else edges traversed. Note that parity 
of c + 6j may be maintained by initializing a C variable ret_b to 6j, then 
complementing ret_b (i.e., by performing a ret_b = ! ret_b statement) when 
a complemented else edge is traversed, and flnally returning ret_b. Note 
that formally this is equivalent to compute the flipping bit b s.t. = 
COBDD_APP{x^, . . . , x„, 1, 1 -x[0], . . . , 1, 1 -x[n- 1], y„ h), being {v,, 6,] = 

This mechanism is implemented inside function K_bits by properly trans- 
lating each COBDD node v E IJi=i Ki^ in a C code block. Each block is 
labeled with a unique label depending on w, and maintains in variable ret_b 
the current parity of c + 6j as described above. This is done by function 
Translate, called on line [7] and detailed in Alg. HI 

Thus, the initial part of function K_bits consists of a switch block (gen- 
erated in lines [T]-|4] of Alg. |3]) which initializes ret_b to bi and then jumps to 
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the label corresponding to node fj. Then, the C code blocks corresponding 
to COBDD nodes are generated in lines [SH7] of Alg. [31 by calling r times 
function Translate (see Alg. H]) with parameters vi,...,Vr- Note that W 
maintains the already translated COBDD nodes. Since function Translate 
only translates nodes not in W, this allows us to exploit sharing not only 
inside each G^P"i\ but also inside G^^^i^, . . . , G^^'"-\ 

Finally, function K is generated in line O Function K simply consists in 
a for loop filling each entry u[i] of the output array u with the boolean 
values returned by K_bits(x, i). Correctness of function GenerateCCode 
is proved in Lemma [6. 4[ 



Algorithm 4 COBDD nodes translation 

Require: COBDD p = (V, V, 1, var, low, high, flip), node v, nodes set 

W CV 
Ensure: Translate{p, v, W): 

1: if V & W then return W 

2: W ^WU{v} 

3: print "L_", v, ":" 

4: if i; = 1 then 

5: print "return ret_b;" 

6: else 

7: let i be s.t. var(t>) = Xi 

8: print "if (x[",i-l, "] == 1) goto L_", high(t;), ";" 

9: if flip(t;) then print "else {ret_b = !ret_b;goto L_",low(w),"; }" 
10: else print "else goto L_", low(f),";" 
11: W ^Translate{p, high(f ), W) 
12: W ^Translate{p, low{v), W) 
13: return W 



Details of Function Translate (Alg. |4]) Given inputs p,v,W, Alg. |4] 

performs a recursive graph traversal of G^''"^ as follows. 

The C code block for internal node v is generated in lines [3] and [THTUl 
The block consists of a label L_v: and an if -then-else C construct. Note 
that label L_v univocally identifies the C code block related to node v. This 
may be implemented by printing the exadecimal value of a pointer to v. 

The if-then-else C construct is generated so as to traverse node v 
in graph G^^^^ in the following way. In line E] the check x[z — 1]= 1 is 
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generated, being i s.t. var(t>) = Xj. The code to take the then edge of v is 
also generated. Namely, it is sufficient to generate a goto statement to the 
C code block related to node high(w). In lines [9] and [10] the code to take 
the else edge is generated, in the case x[i — 1]= 1 is false. In this case, if 
the else edge is complemented, i.e. flip(f) holds (line [9]), it is necessary to 
complement ret_b and then perform a goto statement to the C code block 
related to node low{v) (linelH]). Otherwise, it is sufficient to generate a goto 
statement to the C code block related to node low{v) (line [TOj) . 

Thus, the block generated for an internal node v, for proper i, I and h, 
has one of the following forms: 

• L_v: if (x[z — 1]) goto L_h; else goto LJ; 

• L_v: if (x[i— 1]) goto L_h; else {ret_b = !ret_b; goto LJ;}. 
There are two base cases for the recursion of function Translate: 

• V & W (line[l]), i.e. v has already been translated into a C code block 
as above. In this case, the set of visited COBDD nodes W is directly 
returned (line [1]) without generating any C code. This allows us to 
retain COBDD node sharing; 

• = 1 (line HI), i.e. the terminal node 1 has been reached. In this case, 
the C code block to be generated is simply L_l : return ret_b ; . Note 
that such a block will be generated only once. 

In all other cases, function Translate ends with the recursive calls on the 
then and else edges (lines fTTI - [T2l) . Note that the visited nodes set W passed 
to the second recursive call is the result of the ffist recursive call. Correctness 
of function Translate is proved in Lemma 16.41 

5.4 An Example of Translation 

In this section we show how a node v and a flipping bit 6 of a COBDD p 
with 3 state variables and 2 action variables is translated in K and K_bits C 
functions. This is done by applying Algs. [H [21 13] and [H 

Consider COBDD p = {{uq,ui,xo,Xi,X2}, {0x17, 0x16, 0x15, 0x14, 0x13, 
0x12, 0x11, 0x10, Oxf, Oxe, 1}, 1, var, low, high, ffip). The corresponding G'-^^ 
is shown in Fig. [H Within p, consider mgo K{xo, xi,X2, uq, ui) = |0xl7, 1] = 
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Figure 2: Comput- 
ing first action bit 
for mgo in Fig. [1] 



Figure 1: An mgo example 



Figure 3: Com- 
puting second ac- 
tion bit for mgo in 

Fig.m 



U0U1X0X1X2 + U0U1X0X1X2 + U0U1X1X2 + U0U1X0X1X2 + U0U1X0X1X2 + UqUiXqX2- 

By applying SolveFunctionalEq (see Alg. [2]), we obtain /i(xo,Xi,X2) = 
|0xl5, 1] = XqXi + X0X1X2 + XqXi + X0X1X2 and f2{xo,Xi,X2) = |OxlO, 1] = 
XQX1X2 + X0X1X2 + xqX2- COBDDs for /i and /2 are depicted in Figs. [2] and [3] 
respectively. Note that in this simple example no new nodes have been added 
w.r.t. the COBDD of Fig. [T|, and that node Oxe is shared between G^/'o^is) 
and G^/'oxio)^ Finally, by calling GenerateCCode (see Alg. [3]) on /i,/2, we 
have the C code in Fig. HI 



6 Translation Proof of Correctness 

In this section we prove the correctness of our approach (Theor. 16. 5p . That 
is, we show that the function K we generate indeed implements the given mgo 
K, thus resulting in a correct-by-construction control software. 

We begin by stating four useful lemmata for our proof. Lemma 16.11 is 
useful to prove Lemma [6.21 i.e. to prove correctness of function SolveFunc- 
tionalEq. 

Lemma 6.1. Let K : M"" x M'' M and let fi, . . . Jr be s.t. fi{x) = 
3ui+i,...,UrK{x,fi{x),...,fi^i{x),l,Ui+i,...,Ur)foralli E [r]. Then, 
X e Dom{K) K{x, /i(x), . . . , fr{x)) = 1. 
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int K_bits(int *x, int action) { 


int ret 


_b ; 






/* blocks have been reordered 


*/ 










switch ( act ion ) { case 


0: ret_b 


= 0; 


goto L_ 


.0x15 






case 


1: ret_b 


= 0; 


goto L_ 


.0x10 


} 


L_0xl5 : 


if (x[0] == 1) 


goto L_ 


0x13 ; 












else { ret_b = 


! ret.b ; 


goto 


L_ 


0x14 


} 




L_0xl3 : 


if (x[l] == 1) 


goto L_ 


Oxe ; 












else { ret_b = 


! ret_b ; 


goto 


L_ 


1; } 






L_Oxe : 


if (x[2] == 1) 


goto L_ 


1 ; 












else { ret_b = 


! ret_b ; 


goto 


L_ 


1; } 






L_0xl4 : 


if (x[l] == 1) 


goto L_ 


Oxe ; 












else goto L_l ; 














L_OxlO : 


if (x[0] == 1) 


goto L_ 


Oxe ; 












else { ret_b = 


! ret_b ; 


goto 


L_ 


Oxf ; 


} 




L_Oxf : 


if (x[l] == 1) 


goto L_ 


Oxe ; 












else { ret_b = 


! ret_b ; 


goto 


L_ 


Oxe ; 


} 




L_l : return ret_b ; } 














void K(int 


*x , int *u) { 


int i ; 


for ( 1 




0; i 


< 2; 










u[l] 




K_bits (x 


i) ; } 



Figure 4: C code for mgo in Fig. [T] 



Proof. Let a? G be s.t. x G Dom(A'), i.e. 3u K{x,u) = 1. We prove 
the lemma by induction on r. For r = 1, we have fi{x) = K{x,l). If 
h{x) = 1, we have K{xJ,{x)) = K{x,l) = h{x) = 1. If h{x) = 0, 
we have K{x, fi{x)) = K{x,0), and K{x,0) = 1 since x G Dom(A') and 
K{x,l) = 0. 

Suppose by_ induction that for all K : M"" x B'-^ ^ ^ B 
K{x,fi{x),...Jr-iix)) = 1, ^where for all i G [r - 1] fi{x) = 
3ui+i, . . . ,Ur-i K{x, fi{x), . . . , fi_i{x),l,Ui+i, . . . ,Ur-i). We have that 
X G Dom{K) implies that either x G Dom(i^|,jj=o) or a; G 
Dom(i^|„^=i). Suppose x G Dom{K\ui=i) holds. We have that 
K\u,=i{x,f2{x),...Jr{x)) = l,^where for all i = 2, ...,r f,{x) = 
3ui+i, ...,Ur K\u^=i{x, /2(£c), . . . , fi-i{x), 1, Mj+i, . . . , M^). By construction, 
we have that fi{x) = 1 and fi{x) = fi{x) for i > 2, thus 1 = 
K\u,=i{x, f 2ix), ... Jr{x)) = K{x,f\{x),...,fr{x)). Aualogously, if 5 ^ 
Dom{K\uj=i) Ax e Dom{K\u-^=o) we have that fi{x) = and fi{x) = fi{x) 
for i > 2, thus 1 = K\u,=o{x, hix), . . . , M^)) = K{x, fi{x), . . . , fr{x)). 

□ 

Lemma 16.21 states correctness of function SolveFunctionalEq of Alg. [2j 
Lemma 6.2. Let p = (V, V, 1, var, low, high, flip) be a COBDD with 
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V = XIl^U , V eV he a node, b eM be a flipping bit. Let |f , bj = K{x, u) and 
r = \U\. Then function SolveFunctionalEq{p,v,b) (see Alg.\^ outputs nodes 
vi, . . . ,Vr and boolean values bi, . . . ,br s.t. for all i G [r] {vi, bij = fi{x) and 
X E Dom{K) implies K{x, fi{x), . . . , fr{x)) = 1. 

Proof Correctness of functions COBDD_APP and COBDD_EX 
(and lemma hypotheses) imphes that for all i G [r] fi{x) = 
3ui+i,...,Ur K{x,fi{x),...,fi_i{x),l,Ui+i,...,Ur). By Lemma O 
we have the thesis. 

□ 

Let Translate^dup be a function that works as function Translate of 
Alg. m but that does not take node sharing into account. Function Trans- 
late^dup may be obtained from function Translate by deleting line [1] (high- 
lighted in Alg. H]) and by replacing calls to Translate in lines [TT] and [T2] with 
recursive calls to Translate^dup (with no changes on parameters). Lemma [6^3] 
states correctness of function Translate_dup. 

Lemma 6.3. Let p = (V, V , 1, var, low, high, flip) be a COBDD, v E V 
be a node, b E M be a flipping bit, and W V be a set of nodes. Then 
function Translate-dup{p, v, W) generates a sequence of labeled C statements 
El ... Bk s.t. k >\Vv\ and for all w eV^: 1) label L_w is in B^ for some i 
and 2) starting an execution from label Ljw with \fi E [n] xU — 11= Xi and 
ret_b= b, a return ret_b; statement is invoked in at most 0{p) steps with 
ret_b = |w, bj = fw,b{x) and p = height (w). 

Proof. We prove this lemma by induction on v. Let f = 1, which implies 
lv,bj = b and K = {!}• We have that function Translate-dup{p,v,W) 
generates a single block Bi (thus k = 1 = |Vi|) s.t. Bi =L_1 : return 
ret_b; (lines [3H5] of Alg. H]). Since by hypothesis we have ret_b= b, and 
since starting from Bi the return statement is invoked in 0(1) steps, the 
base case of the induction is proved. 

Let V be an internal node with var(t') = Xi and let f{x) = Since 
w E Vv iS w = v\/ w E Vhigh(t;) y w E V^iow{i'), by induction hypothesis we only 
have to prove the thesis for w = v. We have that f{x) = Xj|high(t'), 6] + 
Xil\ow{v),b®mp{v)j, i.e. f{x) = Xilhigh{v),bj + Xil\ow{v),bj if flip (t;) = 
and f{x) = Xj|high(t;), 6] + Xj|low(i;), 6] if fiip(w) = 1. Since f{x) = 
Xif\xi=i{x)+Xif\^^=o{x), by Theor.iHwe have that |high(t;)_, &] = /|^^=i(cc), 
and that |low(u),6] = f\^^=Q{x) if fiip{v) = and |low(t;),6] = f\^.=Q{x) if 
flip(u) = 1. 
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By lines E] and [5HTU] of Alg. HI we have that function Trans- 
late_dup{p, V, W) generates blocks BBn . . . BihB2i . . . B21 s.t. B =L_v: 
if (x[z — 1] == 1) goto L_high(f ) ; else Be where Be is either goto 
L_low(t;); if flip(t;) = or {ret_b = !ret_b; goto LJow(w) ; } if flip (w) = 
1, and Bii . . . Bih {B21 . . . B21) are generated by the recursive call Trans- 
late_dup{p, highly), W) in line [TT] (Translate_dup( p. \ow(v). W) in line \n\i . 
By induction hypothesis and the above reasoning, if the execution starts at 
label L_high(w) and ret_b= b, then a return ret_b; statement is invoked 
in at most 0{p — 1) steps with ret_b = f\rc.=i{x). As for the else case, 
we have that starting from L_low(w) with ret_b= b (ret_b= b) if fiip(f ) = 
(fiip(t') = 1), then a return ret_b; statement is invoked in at most 0(p — 1) 
steps with ret_b = f\x-=o{x). By construction of block B, starting from label 
L_v, a return ret_b; statement is invoked in at most 0{p — 1 + 1) = 0{p) 
steps with ret_b = Xif\xi=i{x) + Xif\x^=o{x) = f{x). Finally, note that 
by induction hypothesis h > |Vhigh(ii)| and / > |Viow(?;)|5 thus we have that 
k = l + h + l>l + \Vhigh(v) \ + |^iow(«)| > \Vv\. 

□ 

Lemma 16.41 extends Lemma 16.31 by also considering node sharing, thus 
stating correctness of function GenerateCCode of Alg. [3] and function Trans- 
late of Alg. H 

Lemma 6.4. Let p = (V, V, 1, var, low, high, flip) be a COBDD and 
Vi, . . . ,Vr ^ V be r nodes and bi, . . . ,br ^ M be r flipping bits. Then lineslB^ 
of function GenerateCCode{p, vi,bi, . . . ,Vr,br) generate a sequence of labeled 
C statements Bi . . . B^ s.t. k = \ Ul^^ | and for all v e U[^]^Ki-' 1) the 
label Ljv is in Bj for some j and 2) starting an execution from label L_v with 
Vj G [n] x[j — 1]= Xj and ret_b= b, a return ret_b; statement is invoked 
in at most 0{p) steps with ret_b = |t>, b\ = fv,b{.x) and p = height(w). 

Proof. We begin by proving that k = \ U[^]^ K). | . To this aim, we prove that 
for each node v G LIl^^V^-, a unique block B^ is generated. This follows by 
how the nodes set W is managed by function Translate in lines [TH5] of Alg. H] 
and by function GenerateCCode in lines [3H7] of Alg. [31 In fact, function 
Translate, when called on parameters p, v, W, returns a set W 3 W, and 
function GenerateCCode calls Translate by always passing the W resulting 
by the previous call. Since a block is generated for node v only if v is not 
in W, and v is added to W only when a block is generated for node v, this 
proves this part of the lemma. 



21 



As for correctness, we prove this lemma by induction on m, being m the 
number of times that the return W ; statement in hne [T] of Alg. S] is exe- 
cuted. As base of the induction, let m = 1 and let p, v, W be the parameters 
of the recursive call executing the first return W ; statement. Then, by 
construction of function Translate, v has been added to W in some previous 
recursive call with parameters p, v, W. In this previous recursive call, a block 
By with label L_v has been generated. Moreover, for this previous recursive 
call, thus for parameters p, v, W, we are in the hypothesis of Lemma 16. 3[ 
which implies that the induction base is proved. 

Suppose now that the thesis holds for the first m executions of the return 
W ; statement in line [T] of Alg. |H Then, by construction of function Trans- 
late, V has been added to W in some previous recursive call with parameters 
p,v,W. In this previous recursive call, a block with label L_v has been 
generated. Let wi, Wi, . . . , Wm, Wm, be s.t. the m recursive calls executing 
the return W ; statement have parameters p, Vi, Wi (note that they are not 
necessarily distinct). By induction hypothesis, for all i G [m] starting from 
label LjWi with Vj G [n] x[j — 1] = Xj and ret_b= h, a return ret_b; state- 
ment is invoked in at most 0{p) steps with ret_b = fw^^bix). By Lemma 16731 
and its proof, the same holds for all w G K \ {wi, . . . , Wm}, thus it holds for 
all V G K. 

□ 

We are now ready to give our main correctness theorem for function 
Synthesize of Alg. [1] 

Theorem 6.5. Let p = (V, V, 1, var, low, high, flip) be a COBDD with 
V = A'UW, V & V he a node, b be a boolean. Let {v, bj = K{x, u), r = \U\ 
and n = Then function Synthesize{p,v,b) generates a C function void 
K(int *x, int *u) with the following property: for all x G Dom(i^'), if 
before a call to K Vi G [n] x\_i — 1]= Xi, and after the call to K\fi E [r] 
u [z — 1] = Ui, then K{x, u) = 1. 

Furthermore, function K has WCET X]I=i O (height (wj)), being vi, . . . ,Vr 
the nodes output by function SolveFunctionalEq. 

Proof. Let x G Dom(i^) (i.e. 3n K{x, u) = 1) and suppose that for all 
j G [n] X [j — 1] = Xj. By line [9] of Alg. [3l for all i G [r], u [z — 1] will take the 
value returned by K_bits(x, i) . In turn, by line |3] Alg. [3l each K_bits(x, 
i) sets ret_b to bi and makes a jump to label LjVi. By Lemma 16.21 and 
by construction of Synthesize, such bi, . . . ,br and vi, . . . ,Vr are s.t. that 



22 



= fi{x),. ■ ■ ,lvr,brj = fr{x) and K{x,fi{x),...Jr{x)) = 1. By 
Lemma EH the sequence of calls K_bits(x, 1), K_bits(x, r) will in- 
deed return, in at most Yl^j=i O (height (t^j)) steps, fi{x), . . . , fr{x). 

□ 

Corollary 6.6. Let p = {V, V, 1, var, low, high, flip) be a COBDD with 
V = XlijU, V eV be a node, b eM be a boolean. Let |f , bj = K{x, u), r = 
and n = Then the C function K output by function Synthesize{p,v,b) 

has WCETO{rn). 

Proof. The corollary immediately follows from Theor. 16.51 and from the fact 
that, for all v & V , height (f) < n. 

□ 

7 Experimental Results 

We implemented our synthesis algorithm in C programming language, using 
the CUDD package for OBDD based computations. We name the resulting 
tool KSS {Kontrol Software Synthesizer) . KSS is part of a more general tool 
named QKS {Quantized feedback Kontrol Synthesizer [7]). KSS takes as input 
a BLIF file which encodes the OBDD for an mgo K{x,u). Such BLIF file 
also contains information about how to distinguish from state variables x and 
action variables u. Then KSS generates as output a C code file containing 
functions K and K_bits as described in Sect. [51 In this section we present 
our experiments that aim at evaluating effectiveness of KSS. 

7.1 Experimental Settings 

We present experimental results obtained by using KSS on given COBDDs 
pi, . . . , P4 s.t. for all i E [4]: 

• Pi = (Vi, Vi, 1, varj, lowj, high^, flipj, with Vi = Xi\dAi = 
{xi, . . . , X2o}^{ui, . . . , Ui}] thus Hi = 20 and Vi = i (note that Vi C Vj 
for j > z); 

• there exists i^j G Vi,6j G B s.t. = Ki{x,u), being Ki{x,u) the 
COBDD representation of the mgo for a buck DC/DC converter with i 
inputs (see [8] for a description of this system). Ki is an intermediate 
output of the QKS tool described in [7]. 
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Table 1: KSS performaces 



r 


CPU 


MEM 


\K\ 


^punsh 1 


\Sw\ 


% 


1 


2.20e-01 


4.53e+07 


12124 


2545 


2545 


O.OOe+00 


2 


4.20e-01 


5.29e+07 


25246 


5444 


4536 


1.67e+01 


3 


5.20e-01 


5.94e+07 


34741 


10731 


8271 


2.29e+01 


4 


6.30e-01 


6.50e+07 


43065 


15165 


11490 


2.42e+01 



For each pi, we run KSS so as to compute Synthesize{pi,Vi, hi) (see Alg. [T]). 
In the following, we will call {wu, bu, . . . , Wa, bu), with Wji G Vi, bji G B, the 
output of function SolveFunctionalEq{pi, Vi, bi) of Alg. |2l Moreover, we call 
fii, . . . , fa : B" — )• B the i boolean functions s.t. = fji{x). Note 

that, by Lemma I6l2| for all x G Dom(i^'), Ki{x, fii{x), . . . , fu{x)) = 1. 

All our experiments have been carried out on a 3.0 GHz Intel hyper- 
threaded Quad Core Linux PC with 8 GB of RAM. 

7.2 KSS Performance 

In this section we will show the performance (in terms of computation time, 
memory, and output size) of the algorithms discussed in Sect.O Tab. [U show 
our experimental results. The i-th row in Tab. [1] corresponds to experiments 
running KSS so as to compute Synthesize{pi,Vi, bi). Columns in Tab. [T]have 
the following meaning. Column r shows the number of action variables, i.e. 
\Ui\ (note that = 20 for all i G [4]). Column CPU shows the compu- 
tation time of KSS (in sees). Column MEM shows the memory usage for 
KSS (in bytes). Column \K\ shows the number of nodes of the COBDD 
representation for Ki{x,u), i.e. Column shows the number 

of nodes of the COBDD representations oi fu, . . . , fa, without considering 
nodes sharing among such COBDDs. Note that we do consider nodes shar- 
ing inside each fji separately. That is, = iKiijJ is the size of a 
trivial implementation of fu, . . . , fa in which each fji is implemented by a 
stand-alone C function. Column \Sw\ shows the size of the control software 
generated by KSS, i.e. the number of nodes of the COBDD representations 
fii, . . . , fa, considering also nodes sharing among such COBDDs. That is, 
\Sw\ = I U*=i Vwjil is the number of C code blocks generated by lines [5H7] 
of function GenerateCCode in Alg. |3l Finally, Column % shows the gain 
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percentage we obtain by considering node sharing among COBDD represen- 
tations for fu, fii, i.e. (1 - ^^1^)100. 

From Tab. [1] we can see that, in less than 1 second and within 70 MB 
of RAM we are able to synthesize the control software for the multi-input 
buck with r = 4 action variables, starting from a COBDD representation of 
K with about 4 x 10^ nodes. The control software we synthesize in such a 
case has about 1.2 x 10^ lines of code, whilest a control software not taking 
into account COBDD nodes sharing would have had about 1.5 x 10^ lines of 
code. Thus, we obtain a 24% gain towards a trivial implementation. 

8 Conclusions 

We presented an algorithm and a tool KSS implementing it which, starting 
from a boolean relation K representing the set of implementations meeting 
the given system specifications, generates a correct-by-construction C code 
implementing K. This entails finding boolean functions F s.t. K{x, F{x)) = 
1 holds, and then implement such F. WCET for the generated control soft- 
ware is at most linear in nr, being = |x| the number of input arguments 
for functions in F and r the number of functions in F. Furthermore, we 
formally proved that our algorithm is correct. 

KSS allows us to synthesize correct-by-construction control software, pro- 
vided that K is provably correct w.r.t. initial formal specifications. This is 
the case in [7], thus this methodology e.g. allows to synthesize correct-by- 
construction control software starting from formal specifications for DTLHSs. 
We have shown feasibility of our proposed approach by presenting experimen- 
tal results on using it to synthesize C controllers for a buck DC-DC converter. 

In order to speed-up the resulting WCET, a natural possible future re- 
search direction is to investigate how to parallelize the generated control 
software, as well as to improve don't-cares handling in F. 
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